home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 1⁄5⁄90 / 0316-Re[2] Persistence --Jan90 < prev    next >
Encoding:
Text File  |  1990-01-05  |  2.5 KB  |  60 lines  |  [TEXT/GEOL]
  1. Item    8074935                         4-Jan-90        12:07
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     MADA2                           MacApp Dev Assoc, Curtis Faith
  6.         MACAPP.TECH$                    MacApp Technical
  7.  
  8. Sub:    RE>RE- Persistence - Obje
  9.  
  10. Attn: MacApp Dev Assoc, Curtis Faith
  11. Attn: MacApp Tech
  12. SentBy: Larry Rosenstein
  13. Date   1/4/90
  14. Subject    RE>RE- Persistence - Object
  15. From   Larry Rosenstein
  16. To MacApp Dev Assoc, Curtis Faith
  17.    MacApp Tech
  18.  
  19.          Reply to:   RE>RE: Persistence - Object I/
  20. Curtis,
  21.  
  22. I don't think you necessarily have to be limited to a tree structure, although
  23. you do have to worry about saving all the objects in the heap because they all
  24. refer to one another.  Handling shared references is conceptually simple.
  25. When you write an object, you assign it an ID.  If you write the same object
  26. again, you write the ID rather than letting the object write itself.
  27.  
  28. When reading, you have to keep a table mapping the IDs to objects that have
  29. been created.  When you read an object you create it and enter it into the
  30. table.  When you see an object ID, you look it up in the table rather than
  31. creating another object.
  32.  
  33. I think if you restrict yourself to reading the stream from start to finish,
  34. then you will always create the object before encountering its ID.  You might
  35. also want to optimize the case where you know there aren't multiple references
  36. to a particular object.  (Then it doesn't need to be assigned an ID.)
  37.  
  38. Note that you can use the same code to write an object to a stream to write an
  39. object to an InsideOut database.  You can implement a subclass of TStream or
  40. write the object to a handle and store the data in the database.  So you only
  41. have to go through the trouble of writing ReadFrom and WriteTo once.
  42.  
  43. You can use your idea of defining ranges of bytes as well.  The TStream class
  44. supports reading and writing an arbitrary series of bytes.
  45.  
  46. When SADE supports Object Pascal, it might be possible to examine the SADE
  47. information to find out the field layout of an object.  You could write a
  48. utility that converted this info into a compact resource.  Then ReadFrom and
  49. WriteTo could have a useful default that looked at this info an did the
  50. appropriate thing.
  51.  
  52. Jeff's description of an object caching scheme is a logical extension of the
  53. capability of writing objects to a stream.  It requires a more sophisticated
  54. implementation because you need to address individual objects, and you need to
  55. manage objects in memory and on the disk.
  56.  
  57. Larry Rosenstein
  58.  
  59.  
  60.